home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000133_owner-urn-ietf _Tue Nov 12 10:52:18 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19931 for urn-ietf-out; Tue, 12 Nov 1996 10:52:18 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19926 for <urn-ietf@services.bunyip.com>; Tue, 12 Nov 1996 10:52:14 -0500
  3. Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA01325  (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 10:51:56 -0500
  5. Received: from  jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C)
  6.     id AA08366; Tue, 12 Nov 96 16:56:56 +0100
  7. Received: by  jrc.it (5.x/EB-950213-L)
  8.     id AA05330; Tue, 12 Nov 1996 16:50:36 +0100
  9. Date: Tue, 12 Nov 1996 16:50:36 +0100
  10. From: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  11. Message-Id: <9611121550.AA05330@ jrc.it>
  12. To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no,
  13.         jayhawk@ds.internic.net
  14. Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
  15. Cc: FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch,
  16.         moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com
  17. X-Sun-Charset: US-ASCII
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: "Dirk.vanGulik" <Dirk.vanGulik@jrc.it>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. > To me, the extension (as written) has a couple of holes.  The URN has to have
  24. > information about the namespace so that the resolver can resolve the URN
  25. > correctly (it took me a while to realize that the proper parsing of option B is
  26. > the second ":").  Therefore, having no meaning after the optional "urn:"
  27. > doesn't work.
  28.  
  29. I realized this as well; but was (and still am) unsure how to effectuate this;
  30. because is implies that the bit between the first to ':' is really limited in
  31. encoding. Something which has bothered me in the syntax document. But I have
  32. no immediate solution for it.
  33.  
  34. > The second hole is that while having an interpretation for a specific namespace
  35. > defined in a separate namespace document is reasonable (in fact I don't see
  36. > how to avoid it) defining general castings in external documents doesn't
  37.  
  38. No, the MIB refernce was meant half in yest; and in fact I hope it will not
  39. come to this; i.e. that most generic clients using URNs will simply hardly
  40. ever show them to the user. However for very specialist (and also for practical
  41. reasons) people close to the data might like specific castings a lot; especialy
  42. when the keys in your mother database are easily derivable. But the rest of the
  43. world should not care; and the references in external document  to the display
  44. encoding is really only there to satisfy the curiosity and the very specialist
  45. users of that NS.
  46.  
  47. > strike me as a big win.  I still believe we can keep the syntax doc reasonably
  48. > short while solving the small problem in front of us.
  49.  
  50. Well: (Which each char actualy being an octet, etc..)
  51.  
  52.     [<] urn:NS:OPS [>]
  53.  
  54.     NS consists of A..Z, 0..9
  55.     OPS consists of A..Z, 0..9, '-', '_' and '.'
  56.  
  57.     The '-','_','.' are kept in reserve for the NS
  58.  
  59.     Whitespace is allowed
  60.  
  61. Would be kind of simple.
  62.  
  63. > This being said, if the holes are plugged up, option D could be a reasonable
  64. > alternative
  65. > 
  66. > Now, back to Harald's proposals, I'll try to synopsize them with my thoughts 
  67. > on the tradeoffs
  68. > 
  69. > >A
  70. > >> - The URN syntax doc says that URNs are sequences of ASCII
  71. > >>   characters (or some subset thereof)
  72. > 
  73. > This is of course, the simplest.  A minimum of transport encoding would be
  74. > involved.  There may be some reserved characters that would be need to be
  75. > encoded on a namespace specific basis but those could be done with
  76. > %HH encoding.
  77.  
  78. Which would imply namespace specific encapsulation needs; which kind of imposes
  79. external NS knowledge on arbritary clients.
  80.  
  81. > >B
  82. > >> - The URN syntax doc says that URNs are sequences of OCTETS,
  83. > >>   with no meaning assigned by the URN syntax doc after the
  84. > >>   second  ':'
  85. > 
  86. > I've modified the above to point up the ':' character.  This is the "opaque string"
  87. > option.  This option would require some transport encoding for 8-bit unclean pipes.
  88. > I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
  89. > something like the %HH scheme would be needed.  For others, the %HH scheme
  90. > could be mixed with actual glyphs that are representation of that octet (or sequence
  91. > of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
  92. > CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
  93. > The other difficulty is that reserved characters have to be limited to
  94. > a subset of ASCII or there is the possibility for encoding collisions that would require
  95. > the syntax doc to specify its own encoding scheme.
  96. > 
  97.  
  98. Somehow not very practical ? IMHO.
  99.  
  100. Dw.